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Abstract 
This document describes the View-based Access Control Model for use 
in the SNMP architecture [RFC2261]. It defines the Elements of 
Procedure for controlling access to management information. This 
document also includes a MIB for remotely managing the configuration 


parameters for the View-based Access Control Model. 
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1. Introduction 


The Architecture for describing Internet Management Frameworks 
[RFC2261] describes that an SNMP engine is composed of: 


a Dispatcher 

a Message Processing Subsystem, 
a Security Subsystem, and 

an Access Control Subsystem. 


) 
) 
) 
) 


AUNE 


Applications make use of the services of these subsystems. 


It is important to understand the SNMP architecture and its 
terminology to understand where the View-based Access Control Model 
described in this document fits into the architecture and interacts 
with other subsystems within the architecture. The reader is 
expected to have read and understood the description and terminology 
of the SNMP architecture, as defined in [RFC2261]. 


The Access Control Subsystem of an SNMP engine has the responsibility 
for checking whether a specific type of access (read, write, notify) 
to a particular object (instance) is allowed. 


It is the purpose of this document to define a specific model of the 
Access Control Subsystem, designated the View-based Access Control 
Model. Note that this is not necessarily the only Access Control 
Model. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

1.2. Access Control 
Access Control occurs (either implicitly or explicitly) in an SNMP 


entity when processing SNMP retrieval or modification request 
messages from an SNMP entity. For example a Command Responder 
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application applies Access Control when processing requests that it 
received from a Command Generator application. These requests 
include these types of operations: GetRequest, GetNextRequest, 
GetBulkRequest, and SetRequest operations. 


Access Control also occurs in an SNMP entity when an SNMP 
notification message is generated (by a Notification Originator 
application). These notification messages include these types of 
operations: InformRequest and SNMPv2-Trap operations. 


The View-based Access Control Model defines a set of services that an 
application (such as a Command Responder or a Notification Originator 
application) can use for checking access rights. It is the 
responsibility of the application to make the proper service calls 
for access checking. 


1.3. Local Configuration Datastore 


To implement the model described in this document, an SNMP entity 
needs to retain information about access rights and policies. This 
information is part of the SNMP engine’s Local Configuration 
Datastore (LCD). See [RFC2261] for the definition of LCD. 


In order to allow an SNMP entity’s LCD to be remotely configured, 
portions of the LCD need to be accessible as managed objects. A MIB 
module, the View-based Access Control Model Configuration MIB, which 
defines these managed object types is included in this document. 


2. Elements of the Model 


This section contains definitions to realize the access control 
service provided by the View-based Access Control Model. 


2.1. Groups 


A group is a set of zero or more <securityModel, securityName> tuples 
on whose behalf SNMP management objects can be accessed. A group 
defines the access rights afforded to all securityNames which belong 
to that group. The combination of a securityModel and a securityName 
maps to at most one group. A group is identified by a groupName. 


The Access Control module assumes that the securityName has already 
been authenticated as needed and provides no further authentication 
of its own. 


The View-based Access Control Model uses the securityModel and the 


securityName as inputs to the Access Control module when called to 
check for access rights. It determines the groupName as a function 
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of securityModel and securityName. 
2.2. securityLevel 


Different access rights for members of a group can be defined for 
different levels of security, i.e., noAuthNoPriv, authNoPriv, and 
authPriv. The securityLevel identifies the level of security that 
will be assumed when checking for access rights. See the SNMP 

Architecture document [RFC2261] for a definition of securitylLevel. 


The View-based Access Control Model requires that the securityLevel 
is passed as input to the Access Control module when called to check 
for access rights. 


2.3. Contexts 


An SNMP context is a collection of management information accessible 
by an SNMP entity. An item of management information may exist in 
more than one context. An SNMP entity potentially has access to many 
contexts. Details about the naming of management information can be 
found in the SNMP Architecture document [RFC2261]. 


The View-based Access Control Model defines a vacmContextTable that 
lists the locally available contexts by contextName. 


2.4. MIB Views and View Families 


For security reasons, it is often valuable to be able to restrict the 
access rights of some groups to only a subset of the management 
information in the management domain. To provide this capability, 
access to a context is via a "MIB view" which details a specific set 
of managed object types (and optionally, the specific instances of 
object types) within that context. For example, for a given context, 
there will typically always be one MIB view which provides access to 
all management information in that context, and often there will be 
other MIB views each of which contains some subset of the 
information. So, the access allowed for a group can be restricted in 
the desired manner by specifying its rights in terms of the 
particular (subset) MIB view it can access within each appropriate 
context. 


Since managed object types (and their instances) are identified via 
the tree-like naming structure of ISO’s OBJECT IDENTIFIERs [ISO- 
ASN.1, RFC1902], it is convenient to define a MIB view as the 
combination of a set of "view subtrees", where each view subtree is a 
subtree within the managed object naming tree. Thus, a simple MIB 
view (e.g., all managed objects within the Internet Network 
Management Framework) can be defined as a single view subtree, while 
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more complicated MIB views (e.g., all information relevant to a 
particular network interface) can be represented by the union of 
multiple view subtrees. 


While any set of managed objects can be described by the union of 
some number of view subtrees, situations can arise that would require 
a very large number of view subtrees. This could happen, for 
example, when specifying all columns in one conceptual row of a MIB 
table because they would appear in separate subtrees, one per column, 
each with a very similar format. Because the formats are similar, 
the required set of subtrees can easily be aggregated into one 
structure. This structure is named a family of view subtrees after 
the set of subtrees that it conceptually represents. A family of 
view subtrees can either be included or excluded from a MIB view. 


2.4.1. View Subtree 


A view subtree is the set of all MIB object instances which have a 
common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree 
is identified by the OBJECT IDENTIFIER value which is the longest 
OBJECT IDENTIFIER prefix common to all (potential) MIB object 
instances in that subtree. 


2.4.2. ViewTreeFamily 


A family of view subtrees is a pairing of an OBJECT IDENTIFIER value 
(called the family name) together with a bit string value (called the 
family mask). The family mask indicates which sub-identifiers of the 
associated family name are significant to the family’s definition. 


For each possible managed object instance, that instance belongs to a 
particular ViewTreeFamily if both of the following conditions are 
true: 


-— the OBJECT IDENTIFIER name of the managed object instance 
contains at least as many sub-identifiers as does the family name, 
and 


—- each sub-identifier in the OBJECT IDENTIFIER name of the managed 
object instance matches the corresponding sub-identifier of the 
family name whenever the corresponding bit of the associated family 
mask is non-zero. 
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When the configured value of the family mask is all ones, the view 
subtree family is identical to the single view subtree identified by 
the family name. 


When the configured value of the family mask is shorter than required 
to perform the above test, its value is implicitly extended with 
ones. Consequently, a view subtree family having a family mask of 
zero length always corresponds to a single view subtree. 


2.5. Access Policy 


The View-based Access Control Model determines the access rights of a 
group, representing zero or more securityNames which have the same 
access rights. For a particular context, identified by contextName, 
to which a group, identified by groupName, has access using a 
particular securityModel and securityLevel, that group’s access 
rights are given by a read-view, a write-view and a notify-view. 


The read-view represents the set of object instances authorized for 
the group when reading objects. Reading objects occurs when 
processing a retrieval (for example a GetRequest, GetNextRequest, 
GetBulkRequest) operation. 


The write-view represents the set of object instances authorized for 
the group when writing objects. Writing objects occurs when 
processing a write (for example a Set) operation. 


The notify-view represents the set of object instances authorized for 
the group when sending objects in a notification, such as when 
sending a notification (for example an Inform or SNMPv2-Trap). 


3. Elements of Procedure 


This section describes the procedures followed by an Access Control 
module that implements the View-based Access Control Model when 
checking access rights as requested by an application (for example a 
Command Responder or a Notification Originator application). The 
abstract service primitive is: 


statusInformation = —- success or errorIndication 
isAccessAllowed ( 

securityModel —- Security Model in use 
securityName —- principal who wants access 
securityLevel -—- Level of Security 
viewType -—- read, write, or notify view 
contextName -- context containing variableName 
variableName -—- OID for the managed object 


) 
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The abstract data elements are: 


statusInformation - one of the following: 


sec 
sec 
sec 
vie 
con 
var 


Wijnen, 


accessAllowed 
notInView 


noSuchView 


noSuchContext 


noGroupName 


noAccessEntry 


otherError 
urityModel 
urityName - 
urityLevel 
wlype a 
textName = 
iableName - 


et. al. 


- a MIB view was found and access is granted. 

- a MIB view was found but access is denied. 
The variableName is not in the configured 
MIB view for the specified viewType (e.g., in 
the relevant entry in the vacmAccessTable). 

- no MIB view found because no view has been 
configured for specified viewType (e.g., in 
the relevant entry in the vacmAccessTable). 

—- no MIB view found because of no entry in the 
vacmContextTable for specified contextName. 

-— no MIB view found because no entry has been 
configured in the vacmSecurityToGroupTable 
for the specified combination of 
securityModel and securityName. 

—- no MIB view found because no entry has been 
configured in the vacmAccessTable for the 
specified combination of contextName, 
groupName (from vacmSecurityToGroupTable), 
securityModel and securityLevel. 

- failure, an undefined error occurred. 
Security Model under which access is requested. 
the principal on whose behalf access is requested. 
Level of Security under which access is requested. 
view to be checked (read, write or notify). 
context in which access is requested. 
object instance to which access is requested. 
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The following picture shows how the decision for access control is made 
by the View-based Access Control Model. 
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Inputs to the isAccessAllowed service are: 


Security Model in use 
principal who wants to access 
Level of Security 
write, 
context containing variableName 
OID for the managed object 
this is made up of: 


or notify view 


> yes/no 
decision 


(z) 
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- object-type (m) 
- object-instance (n) 


The partial "who" (1), represented by the securityModel (a) and 
the securityName (b), are used as the indices (a,b) into the 
vacmSecurityToGroupTable to find a single entry that produces a 
group, represented by groupName (x). 


The "where" (2), represented by the contextName (e), the "who", 
represented by the groupName (x) from the previous step, and the 
"how" (3), represented by securityModel (a) and securityLevel (c), 
are used as indices (e,x,a,c) into the vacmAccessTable to find a 
single entry that contains three MIB views. 


The "why" (4), represented by the viewType (d), is used to select 
the proper MIB view, represented by a viewName (y), from the 
vacmAccessEntry selected in the previous step. This viewName (y) is 
an index into the vacmViewTreeFamilyTable and selects the set of 
entries that define the variableNames which are included in or 
excluded from the MIB view identified by the viewName (y). 


The "what" (5) type of management data and "which" (6) particular 
instance, represented by the variableName (f), is then checked to be 
in the MIB view or not, e.g., the yes/no decision (z). 


Processing the isAccessAllowed Service Request 


This section describes the procedure followed by an Access Control 


module that implements the View-based Access Control Model whenever 


it receives an isAccessAllowed request. 


1) The vacmContextTable is consulted for information about 
the SNMP context identified by the contextName. If information 
about this SNMP context is absent from the table, then an 
errorIndication (noSuchContext) is returned to the calling module. 


2) The vacmSecurityToGroupTable is consulted for mapping the 
securityModel and securityName to a groupName. If the information 
about this combination is absent from the table, then an 
errorIndication (noGroupName) is returned to the calling module. 


3) The vacmAccessTable is consulted for information about the 
groupName, contextName, securityModel and securityLevel. If 
information about this combination is absent from the table, then 
an errorIndication (noAccessEntry) is returned to the calling 
module. 
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4) a) If the viewType is "read", then the read view is used for 
checking access rights. 
b) If the viewType is "write", then the write view is used for 
checking access rights. 
c) If the viewType is "notify", then the notify view is used 
for checking access rights. 
If the view to be used is the empty view (zero length viewName) 
then an errorIndication (noSuchView) is returned to the calling 
module. 
5) a) If there is no view configured for the specified viewType, 
then an errorIndication (noSuchView) is returned to the calling 
module. 
b) If the specified variableName (object instance) is not in the 
MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in 
section 4), then an errorIndication (notInView) is returned to 
the calling module. 
Otherwise, 
c) The specified variableName is in the MIB view. 
A statusInformation of success (accessAllowed) is returned to 
the calling module. 
4. Definitions 
SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN 
IMPORTS 
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 
MODULE-IDENTITY, OBJECT-TYPE, 
snmpModules FROM SNMPv2-SMI 
TestAndIncr, 
RowStatus, StorageType FROM SNMPv2-TC 
SnmpAdminString, 
SnmpSecurityhLevel, 
SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; 
snmpVacmMIB MODULE-IDENTITY 
LAST-UPDATED "97112000002" -- 20 Nov 1997, midnight 
ORGANIZATION "SNMPv3 Working Group" 
CONTACT-INFO "WG-email: snmpv3@tis.com 
Subscribe: majordomo@tis.com 
In message body: subscribe snmpv3 
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Chair: Russ Mundy 
Trusted Information Systems 

postal: 3060 Washington Rd 
Glenwood MD 21738 
USA 

email: mundy@tis.com 

phone: +1-301-854-6889 

Co-editor: Bert Wijnen 
IBM T.J. Watson Research 

postal: Schagen 33 
3461 GL Linschoten 
Netherlands 

email: wijnen@vnet.ibm.com 

phone: +31-348-432-794 

Co-editor: Randy Presuhn 
BMC Software, Inc 

postal: 1190 Saratoga Avenue, Suite 130 
San Jose, CA 95129-3433 
USA 

email: rpresuhn@bmc.com 

phone: +1-408-556-0720 

Co-editor: Keith McCloghrie 
Cisco Systems, Inc. 

postal: 170 West Tasman Drive 
San Jose, CA 95134-1706 
USA 

email: kzm@cisco.com 

phone: +1-408-526-5260 

" 

DESCRIPTION "The management information definitions for the 


View-based Access Control Model for SNMP. 


::= { snmpModules 5 } 


= Administrative assignments KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmMIBObjects 
vacmMIBConformance 


OBJECT IDENTIFIER { snmpVacmMIB 1 } 
OBJECT IDENTIFIER ::= { snmpVacmMIB 2 } 


ne Information about Local Contexts KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmContextTable OBJECT-TYPE 


SYNTAX SEQUENCE OF VacmContextEntry 
MAX-ACCESS not-accessible 
STATUS current 
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DESCRIPTION "The table of locally available contexts. 


This table provides information to SNMP Command 
Generator applications so that they can properly 
configure the vacmAccessTable to control access to 
all contexts at the SNMP entity. 


This table may change dynamically if the SNMP entity 
allows that contexts are added/deleted dynamically 
(for instance when its configuration changes). Such 
changes would happen only if the management 
instrumentation at that SNMP entity recognizes more 
(or fewer) contexts. 


The presence of entries in this table and of entries 
in the vacmAccessTable are independent. That is, a 
context identified by an entry in this table is not 
necessarily referenced by any entries in the 
vacmAccessTable; and the context(s) referenced by an 
entry in the vacmAccessTable does not necessarily 
currently exist and thus need not be identified by an 
entry in this table. 


This table must be made accessible via the default 
context so that Command Responder applications have 
a standard way of retrieving the information. 


This table is read-only. It cannot be configured via 
SNMP. 


" 


::= { vacmMIBObjects 1 } 


vacmContextEntry OBJECT-TYPE 


SYNTAX VacmContextEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION "Information about a particular context." 
INDEX { 
vacmContextName 


} 


::= { vacmContextTable 1 } 
VacmContextEntry ::= SEQUENCE 
{ 
vacmContextName SnmpAdminString 


} 


vacmContextName OBJECT-TYPE 
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SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION "A human readable name identifying a particular 
context at a particular SNMP entity. 


The empty contextName (zero length) represents the 
default context. 


::= { vacmContextEntry 1 } 


aa Information about Groups KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmSecurityToGroupTable OBJECT-TYPE 


SYNTAX SEQUENCE OF VacmSecurityToGroupEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "This table maps a combination of securityModel and 
securityName into a groupName which is used to define 
an access control policy for a group of principals. 


" 


:= { vacmMIBObjects 2 } 


vacmSecurityToGroupEntry OBJECT-TYPE 


SYNTAX VacmSecurityToGroupEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "An entry in this table maps the combination of a 
securityModel and securityName into a groupName. 


INDEX { 
vacmSecurityModel, 
vacmSecurityName 
} 


::= { vacmSecurityToGroupTable 1 } 


VacmSecurityToGroupEntry ::= SEQUENCE 
{ 
vacmSecurityModel SnmpSecurityModel, 
vacmSecurityName SnmpAdminString, 
vacmGroupName SnmpAdminString, 
vacmSecurityToGroupStorageType StorageType, 
vacmSecurityToGroupStatus RowStatus 


} 
vacmSecurityModel OBJECT-TYPE 


SYNTAX SnmpSecurityModel (1..2147483647) 
MAX-ACCESS not-accessible 
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STATUS current 
DESCRIPTION "The Security Model, by which the vacmSecurityName 
referenced by this entry is provided. 


Note, this object may not take the ’any’ (0) value. 
" 


:= { vacmSecurityToGroupEntry 1 } 


vacmSecurityName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(1..32)) 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The securityName for the principal, represented ina 
Security Model independent format, which is mapped by 
this entry to a groupName. 


The securityName for a principal represented in a 
Security Model independent format. 


" 


::= { vacmSecurityToGroupEntry 2 } 


vacmGroupName OBJECT-TYPE 
SYNTAX SnmpAdminString (SIZE(1..32)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The name of the group to which this entry (e.g., the 
combination of securityModel and securityName) 
belongs. 


This groupName is used as index into the 
vacmAccessTable to select an access control policy. 


" 


::= { vacmSecurityToGroupEntry 3 } 


vacmSecurityToGroupStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The storage type for this conceptual row. 
Conceptual rows having the value /’permanent’ need not 
allow write-access to any columnar objects in the row. 
" 
DEFVAL { nonVolatile } 
:= { vacmSecurityToGroupEntry 4 } 


vacmSecurityToGroupStatus OBJECT-TYPE 
SYNTAX RowStatus 
MAX-ACCESS read-create 
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STATUS current 
DESCRIPTION "The status of this conceptual row. 


The RowStatus TC [RFC1903] requires that this 
DESCRIPTION clause states under which circumstances 
other objects in this row can be modified: 


The value of this object has no effect on whether 
other objects in this conceptual row can be modified. 


" 
::= { vacmSecurityToGroupEntry 5 } 


= Information about Access Rights KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmAccessTable OBJECT-TYPE 


SYNTAX SEQUENCE OF VacmAccessEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The table of access rights for groups. 


Each entry is indexed by a contextPrefix, a groupName 
a securityModel and a securityLevel. To determine 
whether access is allowed, one entry from this table 
needs to be selected and the proper viewName from that 
entry must be used for access control checking. 


To select the proper entry, follow these steps: 


1) the set of possible matches is formed by the 
intersection of the following sets of entries: 
the set of entries with identical vacmGroupName 
the union of these two sets: 
- the set with identical vacmAccessContextPrefix 
- the set of entries with vacmAccessContextMatch 
value of '’prefix’ and matching 
vacmAccessContextPrefix 
intersected with the union of these two sets: 
- the set of entries with identical 
vacmSecurityModel 
- the set of entries with vacmSecurityModel 
value of ’any’ 
intersected with the set of entries with 
vacmAccessSecurityLevel value less than or equal 
to the requested securityLevel 


2) if this set has only one member, we’re done 


otherwise, it comes down to deciding how to weight 
the preferences between ContextPrefixes, 
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SecurityModels, and SecurityLevels as follows: 

a) if the subset of entries with identical 
securityModels is not empty, discard the rest. 

b) if the subset of entries with identical 
vacmAccessContextPrefix is not empty, 
discard the rest 

c) discard all entries with ContextPrefixes shorter 
than the longest one remaining in the set 

d) select the entry with the highest securityLevel 


Please note that for securityLevel noAuthNoPriv, all 
groups are really equivalent since the assumption that 
the securityName has been authenticated does not hold. 


:= { vacmMIBObjects 4 } 


vacmAccessEntry OBJECT-TYPE 


SYNTAX VacmAccessEntry 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "An access right configured in the Local Configuration 
Datastore (LCD) authorizing access to an SNMP context. 
" 
INDEX { vacmGroupName, 
vacmAccessContextPrefix, 
vacmAccessSecurityModel, 
vacmAccessSecurityLevel 


} 
:= { vacmAccessTable 1 } 


VacmAccessEntry ::= SEQUENCE 
{ 

vacmAccessContextPrefix SnmpAdminString, 
vacmAccessSecurityModel SnmpSecurityModel, 
vacmAccessSecurityLevel SnmpSecurityLevel, 
vacmAccessContextMatch INTEGER, 
vacmAccessReadViewName SnmpAdminString, 
vacmAccessWriteViewName SnmpAdminString, 
vacmAccessNotifyViewName SnmpAdminString, 
vacmAccessStorageType StorageType, 
vacmAccessStatus Rowstatus 


} 


vacmAccessContextPrefix OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "In order to gain the access rights allowed by this 


Wijnen, et. al. Standards Track [Page 16] 


RFC 2265 VACM for SNMPv3 January 1998 


conceptual row, a contextName must match exactly 

(if the value of vacmAccessContextMatch is ’exact’) 
or partially (if the value of vacmAccessContextMatch 
is ’prefix’) to the value of the instance of this 
object. 


" 


:= { vacmAccessEntry 1 } 


vacmAccessSecurityModel OBJECT-TYPE 


SYNTAX SnmpSecurityModel 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "In order to gain the access rights allowed by this 
conceptual row, this securityModel must be in use. 


::= { vacmAccessEntry 2 } 


vacmAccessSecurityLevel OBJECT-TYPE 


SYNTAX SnmpSecurityLevel 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The minimum level of security required in order to 
gain the access rights allowed by this conceptual 
row. A securityLevel of noAuthNoPriv is less than 
authNoPriv which in turn is less than authPriv. 


If multiple entries are equally indexed except for 
this vacmAccessSecurityLevel index, then the entry 
which has the highest value for 
vacmAccessSecurityLevel wins. 


::= { vacmAccessEntry 3 } 


vacmAccessContextMatch OBJECT-TYPE 


SYNTAX INTEGER 
{ exact (1), -- exact match of prefix and contextName 
prefix (2) -- Only match to the prefix 


} 

MAX-ACCESS read-create 

STATUS current 

DESCRIPTION "If the value of this object is exact(1), then all 
rows where the contextName exactly matches 
vacmAccessContextPrefix are selected. 


If the value of this object is prefix(2), then all 
rows where the contextName whose starting octets 
exactly match vacmAccessContextPrefix are selected. 
This allows for a simple form of wildcarding. 
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See also the example in the DESCRIPTION clause of 
the vacmAccessTable above. 


::= { vacmAccessEntry 4 } 


vacmAccessReadViewName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The value of an instance of this object identifies 
the MIB view of the SNMP context to which this 
conceptual row authorizes read access. 


The identified MIB view is that one for which the 
vacmViewTreeFamilyViewName has the same value as the 
instance of this object; if the value is the empty 
string or if there is no active MIB view having this 
value of vacmViewTreeFamilyViewName, then no access 
is granted. 
" 
DEFVAL E 22H 4h -—- the empty string 
:= { vacmAccessEntry 5 } 


vacmAccessWriteViewName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The value of an instance of this object identifies 
the MIB view of the SNMP context to which this 
conceptual row authorizes write access. 


The identified MIB view is that one for which the 
vacmViewTreeFamilyViewName has the same value as the 
instance of this object; if the value is the empty 
string or if there is no active MIB view having this 
value of vacmViewTreeFamilyViewName, then no access 
is granted. 
" 

DEFVAL { ’'H } -—- the empty string 

::= { vacmAccessEntry 6 } 


vacmAccessNotifyViewName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(0..32)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The value of an instance of this object identifies 
the MIB view of the SNMP context to which this 
conceptual row authorizes access for notifications. 
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The identified MIB view is that one for which the 
vacmViewTreeFamilyViewName has the same value as the 
instance of this object; if the value is the empty 
string or if there is no active MIB view having this 
value of vacmViewTreeFamilyViewName, then no access 
is granted. 
" 

DEFVAL {0-2 A} -—- the empty string 

::= { vacmAccessEntry 7 } 


vacmAccessStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The storage type for this conceptual row. 


Conceptual rows having the value ’permanent’ need not 
allow write-access to any columnar objects in the row. 


" 


DEFVAL { nonVolatile } 
::= { vacmAccessEntry 8 } 


vacmAccessStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The status of this conceptual row. 


The RowStatus TC [RFC1903] requires that this 
DESCRIPTION clause states under which circumstances 
other objects in this row can be modified: 


The value of this object has no effect on whether 
other objects in this conceptual row can be modified. 


" 
::= { vacmAccessEntry 9 } 
—— Information about MIB views KEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
-- Support for instance-level granularity is optional. 
-—- In some implementations, instance-level access control 


-- granularity may come at a high performance cost. Managers 
-- should avoid requesting such configurations unnecessarily. 


vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 } 


vacmViewSpinLock OBJECT-TYPE 
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SYNTAX 
MAX-ACCESS 
STATUS 
DESCRIPTION "An advisory lock used to allow cooperating SNMP 
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TestAndIncr 
read-write 
current 


Command Generator applications to coordinate their 
use of the Set operation in creating or modifying 
views. 


When creating a new view or altering an existing 
view, it is important to understand the potential 
interactions with other uses of the view. The 
vacmViewSpinLock should be retrieved. The name of 
the view to be created should be determined to be 
unique by the SNMP Command Generator application by 
consulting the vacmViewTreeFamilyTable. Finally, 
the named view may be created (Set), including the 
advisory lock. 

If another SNMP Command Generator application has 
altered the views in the meantime, then the spin 
lock’s value will have changed, and so this creation 
will fail because it will specify the wrong value for 
the spin lock. 


Since this is an advisory lock, the use of this lock 
is not enforced. 


{ vacmMIBViews 1 } 


vacmViewTreeFamilyTable OBJECT-TYPE 
SYNTAX 
MAX-ACCESS 
STATUS 
DESCRIPTION "Locally held information about families of subtrees 
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SEQUENCE OF VacmViewTreeFamilyEntry 
not-accessible 
current 


within MIB views. 


Each MIB view is defined by two sets of view subtrees: 
- the included view subtrees, and 
- the excluded view subtrees. 
Every such view subtree, both the included and the 
excluded ones, is defined in this table. 


To determine if a particular object instance is in 

a particular MIB view, compare the object instance’s 
OBJECT IDENTIFIER with each of the MIB view’s active 
entries in this table. If none match, then the 
object instance is not in the MIB view. If one or 
more match, then the object instance is included in, 
or excluded from, the MIB view according to the 
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value of vacmViewTreeFamilyType in the entry whose 
value of vacmViewTreeFamilySubtree has the most 
sub-identifiers. If multiple entries match and have 
the same number of sub-identifiers, then the 
lexicographically greatest instance of 
vacmViewTreeFamilyType determines the inclusion or 
exclusion. 


An object instance’s OBJECT IDENTIFIER X matches an 
active entry in this table when the number of 
sub-identifiers in X is at least as many as in the 
value of vacmViewTreeFamilySubtree for the entry, 
and each sub-identifier in the value of 
vacmViewTreeFamilySubtree matches its corresponding 
sub-identifier in X. Two sub-identifiers match 
either if the corresponding bit of the value of 
vacmViewTreeFamilyMask for the entry is zero (the 
‘wild card’ value), or if they are equal. 


A ‘family’ of subtrees is the set of subtrees defined 
by a particular combination of values of 
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask. 
In the case where no ’wild card’ is defined in the 
vacmViewTreeFamilyMask, the family of subtrees reduces 
to a single subtree. 


When creating or changing MIB views, an SNMP Command 
Generator application should utilize the 
vacmViewSpinLock to try to avoid collisions. See 
DESCRIPTION clause of vacmViewSpinLock. 


When creating MIB views, it is strongly advised that 
first the ’excluded’ vacmViewTreeFamilyEntries are 
created and then the ’included’ entries. 


When deleting MIB views, it is strongly advised that 
first the ’included’ vacmViewTreeFamilyEntries are 
deleted and then the ’excluded’ entries. 


If a create for an entry for instance-level access 
control is received and the implementation does not 
support instance-level granularity, then an 
inconsistentName error must be returned. 


{ vacmMIBViews 2 } 


vacmViewTreeFamilyEntry OBJECT-TYPE 
SYNTAX 
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MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION "Information on a particular family of view subtrees 
included in or excluded from a particular SNMP 
context’s MIB view. 


Implementations must not restrict the number of 
families of view subtrees for a given MIB view, 
except as dictated by resource constraints on the 
overall number of entries in the 
vacmViewTreeFamilyTable. 


If no conceptual rows exist in this table for a given 
MIB view (viewName), that view may be thought of as 
consisting of the empty set of view subtrees. 
" 
INDEX { vacmViewTreeFamilyViewName, 
vacmViewTreeFamilySubtree 


} 


::= { vacmViewTreeFamilyTable 1 } 


VacmViewTreeFamilyEntry ::= SEQUENCE 
{ 

vacmViewTreeFamilyViewName SnmpAdminString, 
vacmViewTreeFamilySubtree OBJECT IDENTIFIER, 
vacmViewTreeFamilyMask OCTET STRING, 
vacmViewTreeFamilyType INTEGER, 
vacmViewTreeFamilyStorageType StorageType, 
vacmViewTreeFamilyStatus RowStatus 


} 


vacmViewTreeFamilyViewName OBJECT-TYPE 


SYNTAX SnmpAdminString (SIZE(1..32)) 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The human readable name for a family of view subtrees. 


::= { vacmViewTreeFamilyEntry 1 } 


vacmViewTreeFamilySubtree OBJECT-TYPE 


SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION "The MIB subtree which when combined with the 
corresponding instance of vacmViewTreeFamilyMask 
defines a family of view subtrees. 


::= { vacmViewTreeFamilyEntry 2 } 
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vacmViewTreeFamilyMask OBJECT-TYPE 


SYNTAX OCTET STRING (SIZE (0..16)) 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The bit mask which, in combination with the 
corresponding instance of vacmViewTreeFamilySubtree, 
defines a family of view subtrees. 


Each bit of this bit mask corresponds to a 
sub-identifier of vacmViewTreeFamilySubtree, with the 
most significant bit of the i-th octet of this octet 
string value (extended if necessary, see below) 
corresponding to the (8*i - 7)-th sub-identifier, and 
the least significant bit of the i-th octet of this 
octet string corresponding to the (8%*i)-th 
sub-identifier, where i is in the range 1 through 16. 


Each bit of this bit mask specifies whether or not 
the corresponding sub-identifiers must match when 
determining if an OBJECT IDENTIFIER is in this 
family of view subtrees; a ’1’ indicates that an 
exact match must occur; a ’0’ indicates ’wild card’, 
i.e., any sub-identifier value matches. 


Thus, the OBJECT IDENTIFIER X of an object instance 
is contained in a family of view subtrees if, for 
each sub-identifier of the value of 
vacmViewTreeFamilySubtree, either: 


the i-th bit of vacmViewTreeFamilyMask is 0, or 


the i-th sub-identifier of X is equal to the i-th 
sub-identifier of the value of 
vacmViewTreeFamilySubtree. 


If the value of this bit mask is M bits long and 
there are more than M sub-identifiers in the 
corresponding instance of vacmViewTreeFamilySubtree, 
then the bit mask is extended with 1’s to be the 
required length. 


Note that when the value of this object is the 
zero-length string, this extension rule results in 
a mask of all-1’s being used (i.e., no ’wild card’), 
and the family of view subtrees is the one view 
subtree uniquely identified by the corresponding 
instance of vacmViewTreeFamilySubtree. 
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Note that masks of length greater than zero length 
do not need to be supported. In this case this 
object is made read-only. 
" 

DEFVAL {ey 

::= { vacmViewTreeFamilyEntry 3 } 


vacmViewTreeFamilyType OBJECT-TYPE 


SYNTAX INTEGER { included(1), excluded(2) } 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "Indicates whether the corresponding instances of 
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask 
define a family of view subtrees which is included in 
or excluded from the MIB view. 

" 
DEFVAL { included } 
::= { vacmViewTreeFamilyEntry 4 } 


vacmViewTreeFamilyStorageType OBJECT-TYPE 


SYNTAX StorageType 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The storage type for this conceptual row. 


Conceptual rows having the value ’permanent’ need not 
allow write-access to any columnar objects in the row. 
" 
DEFVAL { nonVolatile } 
:= { vacmViewTreeFamilyEntry 5 } 


vacmViewTreeFamilyStatus OBJECT-TYPE 


SYNTAX RowStatus 
MAX-ACCESS read-create 
STATUS current 


DESCRIPTION "The status of this conceptual row. 


The RowStatus TC [RFC1903] requires that this 
DESCRIPTION clause states under which circumstances 
other objects in this row can be modified: 


The value of this object has no effect on whether 
other objects in this conceptual row can be modified. 


:= { vacmViewTreeFamilyEntry 6 } 


as Conformance information KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
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vacmMIBC 


ompliances 


vacmMIBGroups 


OBJECT IDENTIFIER 
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{ vacmMIBConformance 1 } 
{ vacmMIBConformance 2 } 


= Compliance statements KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmMIBCompliance MODULE-COMPLIANCE 
US current 
DESCRIPTION "The compliance statement for SNMP engines which 
implement the SNMP View-based Access Control Model 
configuration MIB. 


STAT 


MODULE -- this module 
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OBJECT 
MIN-ACCESS 
DESCRIPTION 
OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
WRITE-SYNTAX 
MIN-ACCESS 
DESCRIPTION 


OBJECT 
MIN-ACCESS 


MANDATORY-GROUPS { vacmBasicGroup } 


vacmAccessContextMatch 
read-only 


"Write access is not required. 


vacmAccessReadViewName 
read-only 


"Write access is not required. 


vacmAccessWriteViewName 
read-only 


"Write access is not required. 


vacmAccessNotifyViewName 
read-only 


"Write access is not required. 


vacmAccessStorageType 
read-only 


"Write access is not required. 


vacmAccessStatus 
read-only 


"Create/delete/modify access to the 
vacmAccessTable is not required. 


vacmViewTreeFamilyMask 
OCTET STRING (SIZE (0)) 
read-only 


"Support for configuration via SNMP of subtree 
families using wild-cards is not required. 


vacmViewTreeFamilyType 
read-only 
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OBJECT 
MIN-ACCESS read-only 
DESCRIPTION "Write access is not required." 


OBJECT 
MIN-ACCESS read-only 
DESCRIPTION "Create/delete/modify access to the 
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DESCRIPTION "Write access is not required." 


vacmViewTreeFamilyStorageType 


vacmViewTreeFamilyStatus 


vacmViewTreeFamilyTable is not required. 


{ vacmMIBCompliances 1 } 


1998 


aot Units of conformance KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


vacmBasicGroup OBJECT-GROUP 
OBJECTS { 


STAT 


US 


} 


vacmContextName, 
vacmGroupName, 
vacmSecurityToGroupStorageType, 
vacmSecurityToGroupStatus, 
vacmAccessContextMatch, 
vacmAccessReadViewName, 
vacmAccessWriteViewName, 
vacmAccessNotifyViewName, 
vacmAccessStorageType, 
vacmAccessStatus, 
vacmViewSpinLock, 
vacmViewTreeFamilyMask, 
vacmViewTreeFamilyType, 
vacmViewTreeFamilyStorageType, 
vacmViewTreeFamilyStatus 


current 


DESCRIPTION "A collection of objects providing for remote 


END 


configuration of an SNMP engine which implements 
the SNMP View-based Access Control Model. 


{ vacmMIBGroups 1 } 


5. Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 


pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
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might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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7. Security Considerations 
7.1. Recommended Practices 
This document is meant for use in the SNMP architecture. The View- 


based Access Control Model described in this document checks access 
rights to management information based on: 


- contextName, representing a set of management information at the 
managed system where the Access Control module is running. 

— groupName, representing a set of zero or more securityNames. 
The combination of a securityModel and a securityName is mapped 
into a group in the View-based Access Control Model. 

- securityModel under which access is requested. 

- securityLevel under which access is requested. 

- operation performed on the management information. 

—- MIB views for read, write or notify access. 
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When the User-based Access Control module is called for checking 
access rights, it is assumed that the calling module has ensured the 
authentication and privacy aspects as specified by the securityLevel 
that is being passed. 


When creating entries in or deleting entries from the 
vacmViewFamiliyTreeTable it is important to do such in the sequence 
as recommended in the DESCRIPTION clause of the vacmViewFamilityTable 
definition. Otherwise unwanted access may be granted while changing 
the entries in the table. 


7.2. Defining Groups 


The groupNames are used to give access to a group of zero or more 
securityNames. Within the View-Based Access Control Model, a 
groupName is considered to exist if that groupName is listed in the 
vacmSecurityToGroupTable. 


By mapping the combination of a securityModel and securityName into a 
groupName, an SNMP Command Generator application can add/delete 
securityNames to/from a group, if proper access is allowed. 


Further it is important to realize that the grouping of 
<securityModel, securityName> tuples in the vacmSecurityToGroupTable 
does not take securityLevel into account. It is therefore important 
that the security administrator uses the securityLevel index in the 
vacmAccessTable to separate noAuthNoPriv from authPriv and/or 
authNoPriv access. 


7.3. Conformance 


For an implementation of the View-based Access Control Model to be 
conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also 
SHOULD implement the initial configuration, described in appendix A. 
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APPENDIX A - Installation 


A. 


1. Installation Parameters 
During installation, an authoritative SNMP engine which supports this 
View-based Access Control Model SHOULD be configured with several 
initial parameters. These include for the View-based Access Control 
Model: 
A security configuration 
The choice of security configuration determines if initial 
configuration is implemented and if so how. One of three possible 
choices is selected: 
- initial-minimum-security-configuration 
- initial-semi-security-configuration 
—- initial-no-access-configuration 
In the case of a initial-no-access-configuration, there is no initial 
configuration, and so the following steps are irrelevant. 
A default context 
One entry in the vacmContextTable with a contextName of "" (the empty 
string), representing the default context. Note that this table gets 
created automatically if a default context exists. 
no privacy support privacy support 
vacmContextName mm TN 
An initial group 
One entry in the vacmSecurityToGroupTable to allow access to group 
"initial". 
no privacy support privacy support 
vacmSecurityModel 3 (USM) 3 (USM) 
vacmSecurityName "initial" "initial" 
vacmGroupName "initial" "initial" 
vacmSecurityToGroupStorageType anyValidStorageType anyValidStorageType 
vacmSecurityToGroupStatus active active 
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Initial access rights 


Three entries in the vacmAccessTable as follows: 


- read-notify access for securityModel USM, 
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securityLevel 


"noAuthNoPriv" on behalf of securityNames that belong to the group 


"initial" 
contextName "". 


- read-write-notify access for securityModel USM, 


to the <restricted> MIB view in the default context with 


securityLevel 


"authNoPriv" on behalf of securityNames that belong to the group 


tTinitial"- to 
contextName "". 


- if privacy is supported, 


read-write-notify access for securityModel USM, 


the <internet> MIB view in the default context with 


securityLevel 


"authPriv" on behalf of securityNames that belong to the group 


"initial" 
contextName "". 


to the <internet> MIB view in the default context with 


That translates into the following entries in the vacmAccessTable. 


Those columns marked with 


(index) 


really present in this table. 


- One entry to be used for unauthenticated access 


vacmAccessContextPrefix 
vacmGroupName (index) 
vacmSecurityModel (index) 
vacmAccessSecurityLevel 
vacmAccessReadViewName 
vacmAccessWriteViewName 
vacmAccessNotifyViewName 
vacmAccesssStorageType 
vacmAccessStatus 


no privacy support 


tinitiaL" 

3 (USM) 
noAuthNoPriv 
"restricted" 

we 

"restricted" 
anyValidStorageType 
active 


- One entry to be used for authenticated access 


privacy (authNoPriv): 


vacmAccessContextPrefix 
vacmGroupName (index) 
vacmSecurityModel (index) 
vacmAccessSecurityLevel 
vacmAccessReadViewName 


et. al. 


no privacy support 


"initial" 
3 (USM) 
authNoPriv 
"internet" 
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are index-only objects and are not 


(noAuthNoPriv) : 


privacy support 


"initial" 

3 (USM) 
noAuthNoPriv 
"restricted" 

we 

"restricted" 
anyValidStorageType 
active 


but without 


privacy support 


Wind ade" 
3 (USM) 
authNoPriv 
"internet" 
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vacmAccessWriteViewName "internet" "internet" 
vacmAccessNotifyViewName "internet" "internet" 
vacmAccessStorageType anyValidStorageType anyValidStorageType 
vacmAccessStatus active active 


—- One entry to be used for authenticated access with privacy 
(authPriv): 


no privacy support privacy support 


vacmAccessContextPrefix mn 


vacmGroupName (index) "initial" 
vacmSecurityModel (index) 3 (USM) 
vacmAccessSecurityLevel authPriv 
vacmAccessReadViewName "internet" 
vacmAccessWriteViewName "internet" 
vacmAccessNotifyViewName "internet" 
vacmAccessStorageType anyValidStorageType 
vacmAccessStatus active 


5) Two MIB views, of which the second one depends on the security 
configuration. 


- One view, the <internet> view, for authenticated access: 


- the <internet> MIB view is the following subtree: 
"internet" (subtree 1.3.6.1) 


- A second view, the <restricted> view, for unauthenticated 
access. This view is configured according to the selected 


security configuration: 


- For the initial-no-access-configuration there is no default 
initial configuration, so no MIB views are pre-scribed. 


- For the initial-semi-secure-configuration: 


the <restricted> MIB view is the union of these subtrees: 
(a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907] 
(b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907] 
(c) "snmpEngine" (subtree 1.3.6.1.6.3.7.2.1) [RFC2261] 
(d) "snmpMPDStats" (subtree 1.3.6.1.6.3.8.2.1) [RFC2262] 
(e) "usmStats" (subtree 1.3.6.1.6.3.9.2.1) [RFC2264] 


- For the initial-minimum-secure-configuration: 


the <restricted> MIB view is the following subtree. 
"internet" (subtree 1.3.6.1) 
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This translates into the following "internet" entry in the 


vacmViewTreeFamilyTable: 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


In addition it translates into the following "restricted" entries 
in the vacmViewTreeFamilyTable: 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 
vacmViewTreeFamilyType 
vacmViewTreeFamilyStorageType 
vacmViewTreeFamilyStatus 


vacmViewTreeFamilyViewName 
vacmViewTreeFamilySubtree 
vacmViewTreeFamilyMask 


et. al. 
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VACM for SNMPv3 January 1998 
minimum-secure semi-secure 
"internet" "internet" 
1.3.6.1 1.3.6.1 
wee we 
1 (included) 1 (included) 
anyValidStorageType anyValidStorageType 
active active 
minimum-secure semi-secure 
"restricted" "restricted" 
1.3.6.1 oS Ere oe reer oe A 
wee we 
1 (included) 1 (included) 
anyValidStorageType anyValidStorageType 
active active 

"restricted" 

13-3566 e2sdrs a 

we 

1 (included) 
anyValidStorageType 
active 

"restricted" 


Leib 16.38 2a 7 

1 (included) 
anyValidStorageType 
active 


"restricted" 

L3. Gb 26-63) 82.1 

1 (included) 
anyValidStorageType 
active 


"restricted" 
103). Gb 6:03). 9525 1 
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vacmViewTreeFamilyType 1 (included) 
vacmViewTreeFamilyStorageType anyValidStorageType 
vacmViewTreeFamilyStatus active 
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B. 


Full Copyright Statement 
Copyright (C) The Internet Society (1997). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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